Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Refactor gpg import to use machine readable colon format #256

Open
wants to merge 1 commit into
base: 1.25.x
Choose a base branch
from
Open

Refactor gpg import to use machine readable colon format #256

wants to merge 1 commit into from
+319 −12

Conversation

Xerkus
Copy link
Member

@Xerkus Xerkus commented Feb 11, 2024 •
edited
Loading

Q A
Documentation no
Bugfix yes
BC Break no
New Feature no
RFC no
QA yes

Description

Current gpg import uses unstable gpg output to determine if key was imported and to get imported key id.

Unstable format is unreliable, for example gpg 2.4.3 on my machine outputs gpg: key 0x8CA5C026AE941316: secret key imported line that would not match existing regex due to 0x prefix in key id. This is not encountered with gpg used by action but I would call it a bug.

This PR is refactoring gpg key import to use colon delimited machine readable format. Information can be found at https://github.com/gpg/gnupg/blob/master/doc/DETAILS

Additional improvements are to guard against adding keys that do not have secret keys or subkeys with sign capability. Expired keys could cause gpg sign to fail anyway but I do not know how reliable expiry information is in gpg import output.

@Xerkus Xerkus added Bug Something isn't working Enhancement labels Feb 11, 2024
@Xerkus Xerkus marked this pull request as draft February 11, 2024 10:19
@Xerkus Xerkus force-pushed the feature/gpg-import-use-machine-readable-format branch from 592c7de to 5db5062 Compare February 12, 2024 00:51
@Xerkus
Copy link
Member Author

Xerkus commented Feb 12, 2024 •
edited
Loading

I was wrong. gpg --export-secret-subkeys exports primary as stub gnu-dummy. That means primary secret key is always reported as available.

Combination of public primary plus secret subkeys is not realistic, removing check for that.

Stub can not be distinguished from real secret key when using --with-colons listing. That stub is listed as sec# in human readable output when listing keys but not during import.

Subkeys with no secrets are exported as secret stubs as well.

Stub could be detected via --list-packets but imo not worth it.

Extra guards for key validity I added originally are in effect useless, removed them. If key can be imported but has any issues signing it will fail to sign release couple seconds later anyway. Extra checks here would only provide a bit of verbosity at best.

@Xerkus Xerkus force-pushed the feature/gpg-import-use-machine-readable-format branch 3 times, most recently from 29ca5aa to 31720aa Compare February 12, 2024 02:27
@Xerkus Xerkus marked this pull request as ready for review February 12, 2024 02:44
@Xerkus
Refactor gpg import to use machine readable colon format
0174cd0 
Signed-off-by: Aleksei Khudiakov <aleksey@xerkus.pro>
@Xerkus Xerkus force-pushed the feature/gpg-import-use-machine-readable-format branch from 31720aa to 0174cd0 Compare February 12, 2024 03:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
Bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@Xerkus